Шаг 3. Совмещаем merge, rebase и cherry-pick
Мы создали точную копию коммита, находящегося в ветке main. Теперь нужно сделать перебазирование коммита из этой же ветки. Если этого не сделать и сразу влить ветку 04-demo-cherry-pick в main, то слияние пройдёт с использованием режима no-fast-forward. Будет создан коммит слияния, а ещё у нас будет два коммита с одинаковым текстом.
Сделаем небольшое отступление и разберём ещё две дополнительные опции для команды git rebase.
Если мы сейчас пропишем команду git rebase, то скопированный коммит будет сначала прочитан, затем удалён, и только после этого будет добавлен перебазированный коммит. По умолчанию для этого используется опция --no-reapply-cherry-picks (её необязательно прописывать). Но она не очень выгодна: так как коммиты проходят сначала этап прочтения, и при большом количестве коммитов производительность может упасть.
Можно использовать другую опцию — --reapply-cherry-picks. Она позволяет повторно применить скопированные коммиты и заменить старые хэши на новые. То есть те, которые находятся в целевой ветке, и которые нам нужны. Старые хэши также будут удалены после этого.
При использовании и первой, и второй опции итог один — вопрос только в производительности. Кроме того, разработчики Git рекомендуют использовать опцию --reapply-cherry-picks. Дополнительно отметим: если вы будете использовать опцию --no-reapply-cherry-picks или команду git rebase без опций после создания точной копии коммита, то получите в выводе от Git рекомендацию перейти на опцию --reapply-cherry-picks.
Переходим к практике.
Пропишем команду — git rebase main --reapply-cherry-picks.
Мы снова столкнулись с конфликтом. Быстро решим его вручную.
Сначала приведём код к тому же состоянию, что и было до этого.
После этого перейдём в Git Bash и добавим наши изменения в индекс — git add --all.
Затем продолжим перебазирование. Для этого пропишем команду git rebase --continue.
Снова открылся файл COMMIT_EDITMSG. Так как текст коммита редактировать не нужно, просто сохраним файл с помощью сочетания клавиш Ctrl + S, а затем закроем — нажмём на крестик.
Снова вернёмся в Git Bash и увидим конечный вывод команды git rebase.
Там написано, что мы сейчас находимся в состоянии detached HEAD и у нас ещё есть возможность откатить текущее перебазирование. Отмены операций мы тоже будем разбирать, но в другом разделе. Также в этом выводе написано, что удалён старый хэш, который был присвоен коммиту после использования команды git cherry-pick. Давайте проверим, какой сейчас хэш у коммита. Для этого воспользуемся командой git log --oneline -2.
Хэш первого коммита изменился, а второго, который прибыл с ветки main, остался прежним — это нам и нужно.
Теперь переключимся на ветку main, чтобы выполнить слияние. Для этого воспользуемся командой git switch main.
Затем вольём ветку 04-demo-cherry-pick в ветку main. Для этого пропишем команду git merge 04-demo-cherry-pick.
Всё отлично, слияние произошло с использованием режима fast-forward. Конфликтов нет, потому что мы их решили на временной ветке.
Удалим временную ветку — она выполнила свою задачу и больше не нужна нам. Используем команду git branch --delete 04-demo-cherry-pick.
Почти готово — осталось только отправить изменения в удалённый репозиторий. Вводим команду git push.
Изменения отправлены в удалённый репозиторий.